문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 멀티코어 프로세서 (문단 편집) === 멀티코어 프로세서를 제대로 활용하려면? : 멀티스레드 프로그래밍 === 멀티코어와 멀티스레드 용어를 설명하기에 앞서 '''멀티코어는 "하드웨어 관점"에서의 물리적 구성 단위, 멀티스레드/멀티스레딩은 "소프트웨어 관점"에서의 논리적 작업 처리 단위'''라는 차이점이 있다. 당장 멀리 갈 것도 없이 Windows 기준으로 작업 관리자를 열어 보면 실행 중인 프로그램(프로세스)들이 코어 단위가 아닌 스레드 단위로 취급하고 있다. 과거에 코어와 스레드를 같은 개념처럼 취급했던 것은 '코어 개수 = 스레드 개수'인 CPU들만 존재하던 시대였기 때문이다. 그리고 [[SMT]]를 경험하려면 멀티 CPU 시스템인 슈퍼컴퓨터나 메인프레임이 사용된 서버, 데이터 센터, 그나마 스케일이 가장 작은 고성능 워크스테이션 말고는 기회가 없었다. 2002년에 인텔이 구현한 하나의 코어에 양방향 SMT 구현체인 하이퍼스레딩부터 일반 소비자들에게도 SMT가 본격적으로 알려지기 시작했지만 적극적으로 활용한 소프트웨어가 전무에 가까웠고, 코어2 시리즈에서는 하이퍼스레딩이 일시적으로 빠진 모습으로 지속되어서 소비자들이 잊고 지내다가, 2008년 1세대 코어 i 시리즈부터 하이퍼스레딩이 다시 도입되면서 '코어 개수 = 스레드 개수'가 항상 성립되는 것이 아님을 일반 소비자들에게 확실히 각인 시켜주었다. 참고로 하나의 코어에 양방향 SMT는 인텔이 먼저 대중화한 것은 맞지만, 하드웨어가 어떤 형태이든 상관없이 SMT 개념 자체는 인텔이 처음 만든 것이 아니고 1960년대에 진행했던 IBM의 ACS 프로젝트를 통해 등장한 오래된 개념이다. 단지, 하이퍼스레딩 덕분에 싱글코어 싱글스레드 CPU만 존재했던 일반 가정용에서도 SMT를 경험할 수 있게 되었을 뿐이다. 그리고 2000년대 초중반에 특수 분야에서 이미 등장한 지금같은 CPU 하나에 코어 여러 개 탑재된 멀티코어 CPU 시스템이 2005년부터 일반 가정용에도 대중화되면서 하이퍼스레딩같은 기능을 굳이 지원하지 않아도 SMT를 경험할 수 있게 되었다. 따라서, 소프트웨어를 만드는 과정인 프로그래밍 관점에서는 코어 단위가 아닌 스레드 단위를 기준으로 취급한다. "클럭 × IPC = 성능"인 싱글코어와 달리 캐시나 아키텍처의 기여도가 더 높아져서 클럭 × IPC가 스펙만큼 나타내진 못하는 바람에 더 높은 클럭임에도 성능이 오히려 낮은[* 불도저 기반 AMD FX 시리즈, 셀러론 시리즈 등등.] 경우가 있어서 과거와 달리 클럭이 높다고 무조건 좋은 제품이 아니며, 일반유저가 좋은 제품을 고르는게 다소 애매해졌다. 그 대신 전체적으로 어떤 CPU를 선택해도 큰 불편 없이 사용할 수 있는 수준이 되었다. 결국 '코어 하나당 성능 * 코어 개수 * 멀티스레드 활용률'의 세가지 지수를 모두 보아야 CPU 성능을 어느정도 정확하게 가늠할 수 있다('코어 하나당 성능'은 다시 '클럭당 성능(IPC) * 클럭'으로 세분화 할 수 있다.). 펜티엄 20주년 에디션(G3258 AE)을 [[오버클럭]]해서 '코어 하나당 성능'을 높이면 i3-4150을 제치고 상당수 게임 성능에서 [[AMD FX 시리즈]]는 물론이고 [[http://lite.parkoz.com/zboard/view.php?id=over_freeboard&no=17290|인텔 코어 i7(블룸필드)까지 제치는 모습]]이 대표적. 하지만 '멀티스레딩 활용률'이 더 높은 게임(배틀필드 4 등)에서는 듀얼코어의 한계를 보이면서 뒤쳐진다. 물론 다른 게임들에서도 위 CPU들도 오버클럭을 하면 다시 상황이 역전되기도 하지만, [[배틀필드 4]]에서는 '멀티스레딩 활용률' 때문에 그럴 필요조차 없이 뒤쳐진다는 것이 포인트. 네이티브 듀얼코어와 쿼드코어의 경우엔 이 방식이 아니고 그냥 다이 하나에 여러 코어를 올린 것보단 전력을 적게 먹으며, L2 캐시 공유 등의 기술을 탑재하고 나오기 때문에 성능이 좀 더 좋아지는 경향이 있으나, [[AMD]] [[AMD 페넘 시리즈|페넘 시리즈]]의 경우 코어 개개의 성능이 매우 떨어지는 관계로 듀얼코어 두개를 붙여 쿼드코어를 만든 인텔 코어2 쿼드에 처절하게 패배했다. 반면, 코어 개개의 성능이 좋은 편인 인텔 코어 i7(블룸필드)의 경우, [[하이퍼스레딩]]까지 탑재하면서 AMD에게 [[넘사벽]]을 선물했다. 대표적인 성공작은 "[[AMD 애슬론64x2 시리즈]]", "[[AMD 옵테론 시리즈]]", "[[인텔 코어2 시리즈]]", "[[AMD RYZEN 시리즈]]"이다. 온라인 IT 매거진 PCBee에서 2007년 1월 [[코어2 쿼드]]의 런칭에 맞춰 [[http://www.nowntv.com/cpurunner/|쿼드지수 측정]] 웹페이지를 제공하기도 했다. 일종의 멀티 스레드 연산 테스트로 기본 클럭 Q6600의 성능을 100으로 치고 유저의 CPU 성능이 어디까지 나오는지를 측정해 준다. 당시에는 꽤 정직한 결과를 보여줘서 대략적인 CPU 성능을 가늠해볼 수 있는 휼륭한 지표였지만, 시간이 지나 웹 브라우저에서 자바스크립트 엔진 성능에 신경쓰게 되면서 같은 스크립트라고 해도 IE 6 시절보다 몇 배는 빠르게 실행시킬 수 있게 되어 멀쩡한 수치가 나오지 않게 되었다. 같은 노오버 Q6600이라고 해도 IE 9에서 쿼드지수를 측정하면 300점 가량 나온다고 하므로 당시 기준의 점수로 환산하려면 대략 1/3 정도로 계산해주면 될 듯 하다. 물론 IE 역시 11 버전까지 업그레이드되고 [[크롬(웹 브라우저)|크롬]] 등의 다른 웹 브라우저라면 같은 환경에서 더 높은 점수가 나올 수도 있다. 코어 i5 쿼드코어 제품군을 4GHz 정도까지만 오버해도 600이나 700 같은 정신나간 수치가 나오게 되었고, [[AMD ZEN+ 마이크로아키텍처|2700X]]+크롬 조합으로 1700점은 그냥 나온다. 덕분에 성능이 아득히 올라가 버린 시스템들의 점수로 인해 TOP 10 그래프는 [[와장창]] 깨져 있다. 게다가 AMD RYZEN 시리즈의 득세로 주력 CPU가 헥사코어~옥타코어로 올라가 버려서 해당 사이트의 "쿼드코어를 넘는 것은 쿼드코어 뿐이다" 문구가 무색해진 지 오래. x86 호환 CPU의 경우 [[AMD RYZEN 시리즈]]의 '''64코어 128스레드'''인 스레드리퍼 3990X는 $3,990, 인텔의 18코어 36스레드인 코어-X 시리즈의 i9-10980XE는 $1,000이다. [[AMD FX 시리즈]]의 8000 시리즈와 9000시리즈는 8코어 8스레드이며 [[AMD RYZEN 시리즈]]의 라이젠 7은 8코어 16스레드이다. FX-8xxx의 경우 네이티브 여부가 이견이 갈린다. 2코어 1모듈이라 실질적으로는 4코어라고 해야 한다며 소송을 당하기도 했다. 서버용으로는 [[인텔 제온 시리즈|인텔 제온]] 스케일러블 시리즈 중 최상위 플래티넘 시리즈랑 제온 W-시리즈 중 최상위 라인은 28코어 56스레드를, AMD [[AMD EPYC 시리즈|EPYC]]에서는 '''64코어 128스레드'''까지 출시되어 있다. --이 소켓을 2개 끼운다고 생각해 보자.-- 그 외에 모바일 [[ARM(CPU)|ARM]] 계열로는 [[퀄컴 스냅드래곤]]과 [[엑시노스]] 등 여러 종류가 있다. 아키텍처가 달라서 당연히 x86 호환이 안 된다. 2017년 하반기 이후 AMD의 라이젠이 늘어난 코어 수와 함께 대성공하면서 위기의식을 느낀 인텔도 그에 따라 코어 수를 올리기 시작하여 멀티코어의 기준이 4코어에서 6~8코어로 많이 올랐다. 라이젠 이전에는 예전부터 i7마저도 4코어로 유지되었지만 라이젠 이후에는 i5도 6코어로 늘어났으며, 2018년 10월부터는 코어 i9가 일반 데스크탑용 라인에도 나오면서 8코어로 증가되었다. 최고사양을 요구하는 AAA 게임쪽도 이젠 8코어 기준으로 제작하거니와 [[https://www.youtube.com/watch?v=AqBl9frFESI|테스트]]에 의하면 8코어를 다 쓰면서 CPU 사용률이 4코어에 비해 많이 낮다는 점이다. 당장 [[엑스박스 원]]과 [[플레이스테이션 4]] 둘 다 저전력, 저클럭이지만 엄연히 8코어 8스레드 CPU다. 이것 역시 AMD의 작품. 전문 소프트웨어는 이미 오래전부터 멀티스레드에 큰 영향을 받으므로 별 상관없지만 소프트웨어 시장이 큰 변화가 오고 있다는 것. 덕분에 어도비처럼 멀티코어 프로세서를 위한 멀티스레딩 지원 및 패치를 게을리하거나 안 하는 회사들이 점점 욕 얻어먹기 시작하고 있다. 다행히도 어도비 라이트룸처럼 스레드 12개까진 제대로 지원해주는 업데이트가 나온 상태지만 여전히 한계가 존재하고 있다. 이건 소프트웨어를 다시 만들지 않는 이상 힘들 수 밖에 없다. 멀티스레딩을 지원하지 않는 프로그램이라도 멀티코어 프로세서 환경(+OS)에서 어느 정도 성능 향상을 얻을 수 있다. [[운영체제|OS]]에선 자신이 프로그램을 실행하지 않아도 기본적으로 OS에서 알아서 관리하는 수많은 시스템 프로그램이 실행되고 있다. Windows 기준으로 작업 관리자의 프로세스 탭에 몇 개의 프로세스가 있는지 세어 보자. 멀티스레딩을 지원하지 않는 프로그램과 기본적으로 실행되고 있는 프로그램을 다른 스레드로 나눠서 처리하면 성능 상의 이득을 얻을 수 있는 것이다. 코어 한 개 범위 내에서 빨라지는 거긴 하지만 그게 어딘가. 단 그게 최신 게임에서 일어나는 일이라면 확실히 문제일 수도 있다. [[Python]]으로 개발된 [[EVE 온라인]] 같은 경우인데, Python의 특성 상 단일 동작은 반드시 싱글스레드에서 수행되어야 하기 때문에 위와 같은 방식으로 멀티스레딩에 최적화되어 있고, 과부하가 걸리면 이것도 한계가 오게 된다. 게임용 3D 그래픽 API의 대표격인 [[DirectX]]의 Direct3D도 비슷한 문제를 겪고 있다. Direct3D 10 세대까지는 API 구조가 렌더링이 싱글스레드에서 동작하는 것을 상정하고 만들었기 때문에 멀티코어를 사용하기 힘들었다. Direct3D 11부터 Deferred Context가 추가되어 멀티 스레드로 렌더링이 가능해 졌으나, 실제 렌더링 명령은 Immediate Context에서 진행 되기 때문에 전체적인 효율이 아쉬웠는데, Direct3D 12부터 유저 드라이버 모드에도 멀티스레딩을 지원하면서 하드웨어 직접 접근을 지원하면서 전체적인 효율이 개선되었다. Direct3D 12의 발표 자료를 보면, Direct3D 11은 쿼드코어에서 돌릴 경우 첫 번째 스레드(스레드 0)가 다른 스레드보다 오래 걸리는 바람에 그만큼 나머지 3개 스레드들이 놀게 된다. 반면 Direct3D 12는 해당 부분도 4개의 스레드에서 나눠 처리하게 하거나, 아예 해당되는 처리 자체를 줄여서 멀티스레딩의 효율과 속도를 높였다. [[OpenGL#s-3.3|관련 문서]]를 보면 알겠지만 OpenGL도 마찬가지라서 Vulkan을 만들었다. 사실 마이크로소프트는 Vulkan이 핫해지자 마지못해 같은 개념을 적용한 DirectX 12를 내놓았다는 말을 많이 듣는데, 실제로 Vulkan과 DX12 둘 다, 기존 버전에 비해 사용하기 위한 지식과 난이도가 급상승한 데 반해 성능 향상은 잘 알고 쓰지 않으면 미미하거나 오히려 마이너스가 되기 십상이기 때문. ||<(>[[http://lite.parkoz.com/zboard/view.php?id=int_vganews&no=11237|Microsoft DirectX Blog 에 올라온 DirectX 12 정보]][* [[https://i2.ruliweb.com/img/5/3/2/B/532B2B34385CCF0019|전체 슬라이트 직링크]], [[https://bbs.ruliweb.com/xbox/board/300003/read/1344736|직링크 출처 및 전체 발표 내용]]] || ||<:>[[파일:attachment/멀티코어 프로세서/Example.jpg|width=100%]] || ||<(>실전에선 Direct3D 12로 구현한다고 항상 위의 그래프대로 뽑을 수 있는 것은 아니다[* 아래에서 언급되는 원리로, 1번 스레드의 App logic(녹색)이 2번 스레드 App logic과 관련이 있다면? 3번 스레드와 4번 스레드의 처리가 서로 데이터를 교환해가면서 결과에 맞춰서 변하는 거라면? 하는 식으로, 막상 스레드 별로 분리를 하려고 하면 쪼갤 수 없는 이유 투성이가 된다.]. 베스트 케이스 기반 동작 원리 설명 정도로만 참고할 것. || 따라서 CPU에 박힌 코어 여러 개의 성능을 제대로 끌어내려면 여러 개의 코어에게 일거리를 효율적으로 배분하도록 프로그램을 멀티스레딩 구조로 짜 줘야 한다. 멀티스레딩에 최적화가 되어있지 않은 프로그램은 CPU 처리량이 더 필요해도 다른 코어의 도움을 받지 못하고 1번 코어에서만 비비적대며 돌아가거나, 심지어는 '''일감을 달라고 저희들끼리 싸우는 동안 실행 속도는 오히려 더 떨어져 버리는''' 참사가 벌어질 수 있다. 스레드를 만들거나 끝내는 것 자체도 CPU의 일을 추가하는 것이기 때문에, 어설프게 갯수만 늘리면 배달차량을 늘리겠답시고 덤볐다가 옥천허브만 창조하는 꼴이 된다. [[파이썬]] 인터프리터가 한 때 이 문제 때문에 까인 적이 있다. 따라서 실행 성능이 중요시되는 프로그램, 특히 게임은 처음 프로그램을 짤 때부터 멀티코어 프로세서를 생각해야 되는 시대가 되었다. 하지만 멀티스레딩을 이용한 병렬 프로그래밍 자체의 어려움과 직렬화에 가까운 게임 프로그래밍의 특성 상 게임은 멀티코어 프로세서가 대중화된 시대임에도 많은 수의 게임들이 동서양을 가리지 않고 멀티코어를 제대로 활용하는 모습을 보기 어렵다. 이는 딱히 기술력이나 돈의 문제 이전에 병렬화로 성능 향상을 꾀할 수 있는 부분이 게임에서 극히 적을 뿐더러, 적용한다고 해도 성능 향상이 없거나 오히려 더 성능이 내려가기 때문이다. 싱글스레딩의 한계를 극복하기 위해 돌리는 시간이 짧은 시뮬레이션은 그냥 싱글스레드용으로 짠 다음에 시간이 긴 구간은 스크립트를 써서 스레드 여러 개를 동시에 돌리는 식의 기법도 사용되고 있으나 효율은 생각보다 좋지 않다. 병렬화 하드웨어 및 소프트웨어 아키텍처의 발달로 인하여 가장 수혜를 본 분야인 비즈니스 솔루션의 경우, 비동기적(Asynchronous) 실행을 지원함으로써 처리량을 비약적으로 향상시키는 것이 가능했다[* 비동기 실행은 멀티스레드(병렬 실행) 과는 동일한 개념은 아니라는 점에 유의. 극단적으로, 싱글코어 CPU를 잘 활용해서 비동기적 프로그램을 돌리는 것으로 아래의 예에서 나오는 것 같은 원하는 결과를 얻을 수 있다.]. 예를 들어, 웹으로 접속하는 어느 서비스 (웹 사이트나 온라인 정보요청 기능 등)을 생각하자. 각각의 사용자는 서버 컴퓨터에 요청사항이 담긴 통신을 날리고, 서버 프로그램은 네트워크로 들어온 각각의 데이터를 보고 그에 맞게 데이터를 만들어(예를 들어 웹사이트의 html 파일) 되돌려 보낸다. 이 경우, 서버 프로그램은 주문을 받고-처리하고-결과물을 돌려보내는 한 단위로 깔끔하게 작업을 쪼갤 수 있으며, 처리한 작업의 이후 결과를 추적한다거나 처리 결과끼리의 연관성에 따라 특정 다른 처리작업의 순서혹은 내용이 변한다거나 하는 '얽힘' 이 존재하지 않는다. 그래서 데이터가 들어오는 대로 병렬로 작업을 처리하도록 흐름을 확산시키면--천본앵-- 과거 방식의 수 배 내지는 수십 배 이상의 서버 처리량을 달성하는 것이 가능했다. 반면 게임은 실시간으로 모든 요소들이 정확히 동시에, 개발자가 의도한 순서대로 플레이어에게 보여져야 하는 프로그램이다. 코어별로 따로 나눠 작업 돌려서 작업에 차이가 발생하면 플레이어 캐릭터는 등장하지만 NPC 1은 아직 연산이 안되었다고 안 나오고 화면은 나오는데 소리는 안 나오는 이런 상황 만들 수는 없어서 병렬화가 어렵다. 지금도 일부 AAA 게임들만이 4스레드 이상을 지원하는 형편이며, 대다수 게임들은 멀티스레딩을 지원한다 해도 별 의미 없는 경우가 대부분이다. 물론 아예 다른 기능별로 나누는 것은 가능해서 가령 물리연산만 따로 빼서 돌린다던가 하면 싱글스레드만 지원하는 게임보다는 낫겠지만 그런 경우도 물리연산 자체는 스레드 1개만 갈구게 되어 한계가 생기며, 게임 루프 자체의 기본적인 순서는 유지되어야 하므로(모든 유닛의 이동위치 계산이 끝나야 물리연산이나 사정거리 계산을 위한 좌표를 알 수 있다거나, 피격 처리에 의한 HP 계산이 끝나야 특수효과나 능력 발동을 위한 현재 빈사상태 판단을 할 수 있다거나, 해당 프레임의 업데이트가 먼저 이루어져야 해당 프레임에 대응되는 렌더링을 수행할 수 있으니까) 무작정 요소별로 스레드를 뽑아서 돌리면 렌더링은 다 되었는데 업데이트가 아직 안 되어서 버벅거리는 현상이 발생할 수 있다. 이것이 2000년대 중반부터 2010년대 초반까지의 멀티스레딩 지원 게임들로부터 드러난 문제점이었다. 게다가 이 각 요소들이 서로 관계를 맺으면 더욱 더 골치아파진다. 플레이어 캐릭터와 NPC와 아이템이 각각 다른 스레드에서 돌아가고 있다고 가정할 때, 플레이어가 NPC에게 아이템을 주는 장면은 어느 스레드가 맡아야 하는가? 어느 스레드가 맡는다 치면 다른 스레드는 그 결과가 나올 때까지 멀뚱히 기다려야 하는가? 하는 식의 문제이다. 다른 셋이서 협동해서 진행하면 이상적이겠지만 이들간에 약간의 시간차만 나도 플레이어는 아이템을 줬는데 NPC는 못 받았고 아이템은 엉뚱한 데 가버리는 심각한 문제가 발생하게 된다.[* 간단한 방법으로는 '미리 메세지를 보낸 다음 전달한다'가 있지만, 컴퓨터 내에서 미리 메세지를 보낸다는 행동 자체가 그냥 연산하는 것보다 상당한 시간 지연을 부른다. 무작정 여기에만 의존할 수가 없는 것.] 게다가 이건 [[하이젠버그]]로 나타날 가능성이 높다. 저런 버그는 시간차가 나지 않으면 생기지 않는 버그니까. [[http://m.dcinside.com/board/rlike/321084#$]] 이런 상황을 프로그래머가 전부 예측하는 것은 불가능에 가깝다. 다른 것 보다도 이거 때문에 지원이 어려우며, 특히 이는 싱글스레드 프로그램을 멀티스레드 기반으로 옮기기 아주 힘들게 하는 장벽으로 작용한다. 차라리 새로 짜는게 낫다는 평가가 나올 정도. 우회적인 방법으로, 과거처럼 렌더가 완료되고 게임 로직을 차례대로 돌리는것이 아니고 렌더 스레드와 로직 스레드를 나눈 후 로직 스레드에서 스레드 풀을 구현 하여 렌더에서 사용되는 CPU자원 사용을 줄이고 로직의 불규칙한 처리를 대비해 몇 프레임을 미리 대충 추측해서 렌더링 하는 기법도 있다.[* 다만 이런 경우 엄밀히 따지면 사용자에게 보여지는 화면은 내부 게임 로직에 비해 몇프레임 전의 과거를 보게 된다.] 결과적으로 각 코어의 연산 능력도 뛰어나야 하며, 이 코어간 & 스레드간의 데이터 연계 능력이 뛰어나야 좋은 멀티스레딩이 된다. 구식 멀티스레딩의 대표적인 예 중 하나인 [[스타크래프트 2]]는 모든 물량을 죄다 CPU로 처리하는 데 고작 스레드 2개까지만 지원한다. 일반전에서는 문제가 없지만 물량이 쏟아져 나오는 협동전에선 고클럭 CPU가 아닌 이상 렉걸린다. 고클럭 CPU도 일부 사령관 조합에서는 버티기 힘든 렉이 걸린다.[* 그리고 스레드 2개 중에 하나는 어째서인지 신나게 렉걸리는 와중에도 늘 로드율 100퍼를 찍지 않는다. 즉, 가뜩이나 코어 둘 밖에 없는데 하나는 직무유기하여 사실상 1.5~1스레드 수준의 효과밖에 볼 수 없다는 의미이다. 심지어 이 때 GPU 로드율은 오히려 '''떨어진다.''' 고사양 그래픽 카드를 달면, 물량이 별로 없는 초반에는 70~90%까지 찍다가 물량이 늘면 오히려 50% 언저리로 떨어지는 기현상이 생긴다.] 처음부터 2스레드 기반으로 설계한 것이 큰 잘못이다. 다른 예론 어도비 계열 소프트웨어들. 산업 표준이라는 말이 나올 정도로 여러 분야에서 압도적으로 많이 쓰이는 프로그램에 멀티스레딩을 아예 지원하지 않는 것은 아니지만 최적화가 정말로 좋지 않고 전문가용 소프트웨어답지 않게 싱글스레드(고클럭 및 높은 IPC) 성능에 의지하고 있다. 이 때문에 싱글스레드 성능이 우수한 일반 데스크탑용 CPU가 현존 8코어가 최다 코어라서 그 이상으로 아무리 코어 개수가 많아봤자 일반 데스크탑용보다 많은 코어 수의 구성을 위해 레이턴시가 늘어져 싱글스레드 성능이 떨어질 수밖에 없는 HEDT/워크스테이션/서버용 CPU는 의미가 없을 정도. 물론 멀티스레딩에 제대로 최적화된 기능은 싱글스레드 성능이 낮더라도 코어 개수만큼 제대로 성능을 내 준다. [[https://www.youtube.com/watch?v=vVjdhXAdKE0|2019년 기준]]으로 테스트한 결과, 최신 게임들은 멀티스레딩을 제대로 지원하고 있다. 이미 2017년부터 스레드 4개는 이젠 더 이상 쓰기 힘들정도로 요구 스펙이 높아졌으며 게임에 따라 스레드 8개에서 최대 16개까지 지원하는 상태다. 평균 프레임만 봐도 6코어 6스레드와 8코어 8스레드간 20 FPS씩이나 차이는 게임도 있으므로 확실히 최신 게임들은 8코어 8스레드 혹은 그 이상을 기준으로 개발되고 있는 셈이다. 물론 최적화나 기타등등까지 따져봐야하므로 성능차가 생길 수 있다. 게임+방송까지 해야한다면 스레드 16개인 CPU나 아예 방송용 컴퓨터를 조립해야할 정도로 요구스펙이 굉장히 높으므로 게임이라도 코어 개수가 많으면 좋을 수 밖에 없는 상황인데 이게 무려 FHD 기준이다. 4K는 말그대로 포기하는 게 좋을정도. 다행히 실시간 인코딩만큼은 CPU가 아닌 그래픽카드에게 전담할 수 있는 있기 때문에 최신 그래픽카드가 있다면 CPU의 요구 사양을 어느 정도 낮춰 실시간 4K 인코딩이 가능해졌다. 이러한 결과는 최신 게임에서는 위에서 언급된 것과는 아예 다른 구조로 처음부터 프로그램을 제작하기 때문이다. 과거에는 싱글코어 처리하는프로그램을 뜯어고치려고 해도 데이터 간의 얽힘을 해결하기 어려우니 일단 기능적으로 따로따로 가능한 것들을 분해하자는 식이었고, 그래서 '''메인 스레드''' - '''렌더링 스레드''' - '''물리계산 스레드''' - '''사운드 스레드''' 같은 식으로 존재하는 기능의 갯수 정도나 나누는 것이 한계였던 반면, 현대의 최신 게임 아키텍처는 기본적으로 모든 처리를 하나의 흐름에서 흘러가는 것을 전제로 한 채, 데이터 구조와 계산 로직 작성 방법을 연구해서 '1000개의 유닛에 대한 연산을 1000개 작업으로 쪼갤 수 있는 표현법'을 창조하는 데 힘을 쏟았다. 그 결과, 게임 로직의 처리를 커다란 반복작업(굵은 쇠사슬) 대신 자잘하지만 무수한 병렬작업인 하나하나를 연결해 가는(새끼줄) 방식으로 표현할 수 있게 되었다. 이렇게 하면 32코어를 사용하든 128코어를 사용하든, 거의 무조건 작업의 개수가 CPU가 지원하는 스레드 수보다 많게 만드는 것이 가능하기 때문에, 1스레드 당 지푸라기 100가닥씩 처리하느냐, 10가닥씩 처리하느냐 하는 식으로 할당하는 개수만 다르게 하여 항상 최대한의 CPU 스레드에게 일을 시킬 수 있다. (물론, 이런 성과를 얻기 위해서는, 위에서도 언급했듯이 게임의 설계 단계부터 데이터 구조와 처리 로직이 분산처리에 적합하도록 고려해 가며 만들어야 한다.)저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기